1. Field of the Invention
This apparatus and method relates to initializing a Universal Serial Bus device and, in particular, to assigning a unique functional address to a Universal Serial Bus device.
2. Description of the Related Art
Universal Serial Bus (USB) is a standard peripheral interface for attaching personal computers to a wide variety of devices: e.g., digital telephone lines, monitors, modems, mice, printers, scanners, game controllers, keyboards, and other peripherals. A USB thus replaces existing interfaces such as the RS-232C serial ports, parallel ports, PS/2 interface and game/MIDI ports.
In accordance with USB, all attached devices connect to a personal computer through a single connector type using a tiered-star topology. A host personal computer includes a single USB controller. The host controller provides the interface between the USB network and the host personal computer. The host controller controls all accesses to USB resources and monitors the bus topology. A USB hub provides USB attachment points for USB devices.
An example of the tiered-star topology of a USB network is shown in FIG. 1. Host PC 100 is a typical personal computer having a USB port connection via host controller 102. Host controller 102 connects directly to hub 110. Compound device 120, hub 130, and device 140 connect to the host controller 102 through hub 110. Devices 132 and 134 connect to the host controller 102 through hub 130 and through hub 110.
Compound device 120 includes devices 124, 126 and hub 122. Hub 122 of compound device 120 connects to the host controller through hub 110. Devices 124 and 126 of compound device 120 connect to the host controller 102 through hub 122 and through hub 110. A practical example of a compound device would be an integrated printer and fax. The printer could be device 124, and the fax could be device 126.
The tiered-star topography illustrated in FIG. 1 allows data to be transmitted into and out of the host PC 100 to the various devices. When data is transmitted from the host to a device it is transmitted downstream through the interconnecting hubs. When data is transmitted from a device to the host it is transmitted upstream through the interconnecting hubs.
USB hubs and devices may be connected and disconnected without completely re-starting the USB network. Upon connection of a device or hub to an upstream hub the upstream hub will notify the host controller of a change in status. Following USB protocol, the host controller will enable the port of the hub to which the device is connected. The host controller will then assign a unique functional address to each device. Ports are enabled one at a time as the host controller 102 assigns unique functional addresses. Upon connection of a compound device, the host controller assigns a unique functional address to each device contained within the compound device. Returning to FIG. 1, devices 124, 126, 132, 134, and 140 in addition to hubs 110, 122, and 130 will each be assigned a unique functional address upon attachment to the USB network.
Devices 124, 126, 132, 134, and 140 in addition to hubs 110, 122, and 130 will each respond to a default address of 00h until they are assigned the unique functional address. Each of the devices include registers which may be read by the host controller. The registers include a default (DEF) bit, a functional address enable (AE) bit, and a functional address register (FAR). The default bit indicates whether the device will respond to the default address. If it is set, the device will respond to the default address, if it is cleared it will not. The functional address enable bit indicates whether the device will respond to the address stored in the functional address register. If it is set, the device will respond to the address stored in the functional address register, if it is cleared it will not.
All of the devices 124, 126, 132, 134, and 140 attach to the host controller 102 through at least one hub. Each hub has one upstream port and at least one downstream port. Upon attachment or removal of a device on a downstream port, a hub will notify the host controller of a change in status. The host controller then queries the hub to determine the change in status on the hub""s ports.
Upon attachment of a device to one of a hub""s downstream ports, the above procedure is followed to notify the host controller of the attachment of a new device. A hub""s downstream ports are by default disabled until the host controller enables them. Consequently, the host controller will enable the port.
Upon removal of a device from one of a hub""s downstream ports, the hub automatically disables the appropriate port and notifies the host of the change. The host controller updates the topography status to reflect the change.
The process of activating a newly attached device will now be described in greater detail. When a device is attached to a downstream port of a hub, the hub will notify the host controller of the change in status via a status change pipe. The host controller queries the hub to determine which of the downstream ports have experienced a connection. The host controller then issues a port enable and reset command to the appropriate port. The enable command enables the port and provides power to the device. The reset command resets all of the devices registers and state information. The device will respond to a default address and is accessible over a default pipe. The host controller then reads a device descriptor to determine the characteristics of the default pipe. The host then assigns a unique functional address to the device thereby moving the device to the addressed state. The host then reads the configuration information from the device, and writes a configuration value to the device. This moves the device to the configured state.
The transaction for assigning a unique functional address during the above described activation process will now be described in greater detail. These transactions are first described generally, then are described as applied to assigning a unique functional address.
The USB specification defines a control transfer protocol for use in configuring a device. A control transfer is composed of a setup transaction which moves request information from the host to the device, optional data transactions which send data in the direction indicated by the setup transaction, and a status transaction which returns status information from the device to the host.
The occurrence of an IN or OUT data transaction in the control transaction provide three possible transaction sequences: a control write sequence, a control read sequence, and a control no-data sequence. Each of these will now be described in greater detail.
Turning to FIG. 4A, a control write sequence is shown. The control write sequence includes three stages: a setup stage, a data stage and a status stage. The setup stage consists of a SETUP transaction 410 having a DATA0 PID. The SETUP transaction 410 specifies that an OUT data stage will follow. The data stage consists of an OUT transaction 412 having a DATA1 PID. The OUT transaction 412 is followed by an OUT transaction 414 having a DATA0 PID. This transaction is followed by as many transactions as are required to transmit the necessary data from the host. This will depend both upon the size of the data in the host and the size of the transmitted packets. The DATA PID alternates between 1 and 0 for the OUT transactions used in the data stage. The final OUT transaction 416 ends the data stage. The status stage consists of a single IN transaction 418 having a DATA1 PID.
Turning to FIG. 4B, a control read sequence is shown. The control data IN sequence includes three stages: a setup stage, a data stage and a status stage. The setup stage consists of a SETUP transaction 420 having a DATA0 PID. The SETUP transaction 420 specifies that an IN data stage will follow. The data stage consists of an IN transaction 422 having a DATA1 PID. The IN transaction 422 is followed by an IN transaction 424 having a DATA0 PID. This token is followed by as many transaction as are required to transmit the necessary data from the device. This will depend both upon the size of the data in the device and the size of the transmitted packets. The DATA PID alternates between 1 and 0 for the IN transactions used in the data stage. The final IN transaction 426 ends the data stage. The status stage consists of a single IN transaction 428 having a DATA1 PID.
Turning to FIG. 4C, a control no-data sequence is shown. The control no-data sequence includes two stages: a setup stage and a status stage. The setup stage consists of a SETUP transaction 420 having a DATA0 PID. The status stage consists of a single OUT transaction 428 having a DATA1 PID.
A flow chart illustrating a setup transaction is shown in FIG. 3. The transaction begins with SETUP token 310 sent from the host. A setup transaction always includes a DATA0 PID for the data field. The device then responds by sending an ACK handshake to complete the SETUP transaction.
A flow chart illustrating an IN transaction is shown in FIG. 5. The IN transaction begins with an IN token 510 which is sent from the host to the device. The device should then respond with the appropriate DATA packet 512 (either a DATA0 or a DATA1 packet). If, however, the device is temporarily unable to return a DATA packet, it will instead return NAK handshake 514. If the device is unable to return a DATA packet and will require host intervention to recover, it will return a STALL handshake 516. Returning to DATA packet 512, the host will respond with an ACK handshake 518 upon receipt of this packet.
A flow chart illustrating an OUT transaction is shown in FIG. 6. The OUT transaction begins with an OUT token 610 which is sent from the host to the device. The host then sends the appropriate DATA packet 612 (either a DATA0 or a DATA1 packet). If the device receives DATA packet 612 without errors and is ready to receive another packet, it returns ACK handshake 614. If the device receives DATA packet 612 without errors but needs the host to resend the packet, it returns NAK handshake 616. The NAK handshake is used when a DATA packet""s intended function is in a state which temporarily prevents it from receiving the DATA packet. If the device receives the DATA packet 612 but is in a stall condition, it returns a STALL handshake to indicate that the host should not attempt to resend the packet. If the data packet 612 is received with a CRC or bit stuffing error, no handshake is returned.
Upon connection of a device to a host port, the host will use a control write transfer to assign a unique functional address. As described above, a successful control write transfer consists of a SETUP transaction, at least one OUT transactions, and an IN transaction. The SETUP transaction is addressed to the default address. The OUT transaction(s) include the unique functional address for the device. The IN transaction consists of the IN token from the host, a zero-length DATA1 packet from the device to the host, and an ACK handshake from the host to the device.
To enable the functional address, each of the devices 124, 126, 132, 134, and 140 and hubs 110, 122 and 130 in turn sets a functional address bit. After completion of the OUT transactions of a setup control transfer for assigning a unique functional address, a device has received the unique functional address. This address is loaded into the device""s functional address register, and the address enable bit is set. The host then sends an IN token to begin the status stage of a setup control transfer. The status stage is used to confirm completion of the control transfer. Having loaded a unique functional address, the default address bit is cleared upon receipt of the following IN token. The device simultaneously sends a DATA1 packet to the host. The DATA1 packet indicates that the endpoint is now in a condition to be addressed by the host. If the device is experiencing temporary delays, it can transmit instead a NAK handshake packet. Alternatively, if the device is experiencing an error condition, it can transmit a STALL to indicate that the host should not attempt to resend data.
On many USB networks, the transmission of data is not completely errorless. Occasionally data transmissions are corrupted, and any of the above described transmissions may be corrupted.
For example, the zero-length DATA1 packet sent by the device during the status stage may be corrupted or simply lost on it""s way through the USB network to the host. During the window of time after such a loss, the host will not send the appropriate ACK because it has not properly received the DATA1 packet.
Instead, the host may attempt to restart the setup control transfer by sending a SETUP token or an IN token to the default address of the device. As the device has cleared the default address bit, it will no longer respond to this token.
Additionally, the host may have already enabled another hub port connected to an as yet unconfigured device. Although the SETUP token is not directed to the unconfigured device, it will respond. Such a response may cause further errors particularly in the hosts monitoring to the bus topography.
Accordingly, methods and apparatus for avoiding the potential errors resulting from the corruption or loss of data transmissions during the setup control transfer are desired.
It is an object of the invention to provide for robust assignment of a functional address using a setup control transfer.
It is a further object of the invention to complete a functional address assignment even where some of the data transmitted during a setup control transfer may be lost or corrupted.
It is an advantage of the invention to avoid the undefined window of time following the loss or corruption of a status stage DATA1 packet.
It is a feature of one aspect of the invention to enable a unique functional address upon receipt of a valid ACK after the status phase or on a SETUP token for another device.
It is a feature of the invention to accept address assignment in compound devices having multiple functional addresses.
According to one aspect of the invention a USB device has a default address, and a default address enable bit wherein the default address enable bit enables the use of the default address. The device receives an IN token from a host; sends a DATA1 packet to the host; receives an ACK from the host; and clears the default address bit only after receiving the ACK.
According to another aspect of the invention a USB device has a default address, and a default address enable bit wherein the default address enable bit enables the use of the default address. The device receives an IN token from a host; sends a zero-length DATA1 packet to the host; receives a SETUP packet from the host; and clears the default address enable bit upon receipt of the SETUP packet.
According to another aspect of the invention a USB network includes a host and a plurality of devices, wherein the devices are of the type having a default address and a default address enable bit, and further wherein the default address enable bit enables the use of the default address. A method for operating the USB network sends an IN token from the host to a first device; receives the IN token by the first device; sends a DATA1 packet from the first device to the host; receives the DATA1 packet by the host; sends an ACK from the host to the first device; sends a SETUP token from the host to a second device; and clears the default address bit of the first device upon receipt of one of the ACK or the SETUP token.
According to another aspect of the invention, a USB device utilizes a default address enable bit, wherein when the default address enable bit is set the USB device responds to a default address and when the default address bit is cleared the USB device does not respond to the default address, and further wherein the default address enable bit is cleared upon receipt of an ACK handshake during a status stage of a control transfer.
These and other objects, features, and advantages will become apparent when considered with reference to the following description and the accompanying drawings.